Herzlich willkommen zum zweiten Kammerstrack.

Ich glaube, ich soll sagen, wer nicht aufgezeichnet werden will, soll sich am besten zu meiner Reihenfelde ganz hinten setzen.

Dann haben wir hier noch eine Liste.

Ok, ja, also, sehr gut Marcel. Ja, also, herzlich willkommen. Das heutige Thema, wie schon angekündigt, ist Web-Singlesign-On.

Und genauer so bei uns an der FAU. Zur Agenda ganz kurz, besteht aus anscheinend fünf Punkten.

Und zwar eine kurze Einführung, das heißt, was ist überhaupt der FSO?

Ich versuche jetzt im Vortrag, so wenig wie möglich auf die technischen Einzelheiten einzugehen, sondern einfach allgemeines Verständnis zu schaffen.

Der zweite Punkt ist dann die Historie, das heißt, wie hat sich das Ganze an der FAU entwickelt.

Der dritte Punkt ist dann die Technik, das heißt, wie hat es damals ausgesehen, wie sieht heute die Technik aus, die hinter dem SSO steht.

Der vierte Punkt, etwas kurz vielleicht, aber wie bringe ich eine eigene Anwendung, das heißt, wenn ich eine eigene Web-Anwendung hier an der FAU betreibe,

wie bringe ich die an das Web-SSO? Und der fünfte Punkt ist das Fazit, eine Überraschung oder ein kleiner Lückenfutter zum Schluss.

Genau, zur Einführung. Also, wieso man das Ganze überhaupt machen, woher kommt das Ganze und so die wichtigsten Begrifflichkeiten,

die man jetzt aus diesem Vortrag vielleicht mitnehmen sollte.

Eigentlich hat alles damit begonnen, dass man irgendwelche Web-Dienste von einem Anbieter, möglicherweise einem externen Anbieter, nutzen möchte.

Mir hat es früher, ist es früher, vonstatten gegangen. Ich habe hier etwas durchgestrichen als ersten Punkt bei der Umsetzung,

und zwar einen lokalen Account bei diesem Anbieter. Da fällt natürlich dann weg, dass man ein Benutzer einer Einrichtung ist.

Also, wenn man sich irgendwo lokal anmelde, dann ist man bei dem registriert, aber man hat keinen Bezug zu irgendeiner Institution, jetzt wie der FAU.

Was früher tatsächlich passiert ist, dass man externen Anbietern Zugriff auf bei uns vorhandene Elternverzeichnisse gegeben hat.

Das heißt, ein Benutzer konnte sich anmelden und die Autorenfizierung lief hinten gegen unseren Elternverzeichnungsverfahren.

Was auch ein ergängiges Verfahren war, war der Austausch von Benutzerdaten. Das heißt, kann man sich richtig schön vorstellen,

in CSV-Dateien, Login-Name und Benutzer-Hash wurde verteilt, wurde aktualisiert, auch nicht möglich, das war es.

Das Hauptproblem bei diesem ganzen Verfahren ist eigentlich, dass sich der Benutzer mit seinem Passwort bei diesem externen Dienstleister oder Anbieter anmeldet.

Das heißt, in dem Augenblick, wo er sich anmeldet, hat natürlich ein bösartiger Anbieter, kann er das Passwort abgreifen und gegen den Benutzer vielleicht verwenden.

Wie sieht es heutzutage aus? Die Anforderungen sind dasselbe. Ein Benutzer unserer Einrichtung will einen Webdienst nutzen.

Das sieht jetzt so aus, ganz allgemein gesprochen. Es gibt eine Art Vertrauensstellung zwischen unserer Einrichtung und dem Anbieter.

Wenn sich, wie es jetzt auch immer technisch vonstatten geht, wenn sich ein Benutzer mit ihm anmeldet,

kriegt er von uns sozusagen nur noch irgendwelche Attribute zugesichert. Das heißt, er ist vielleicht Mitarbeiter oder vielleicht auch die Kennung, je nachdem, was er braucht.

Genau, entscheidend ist auch, dass er definitiv nicht alle Benutzer kriegt, sondern immer nur, wenn sich jemand bei ihm anmeldet.

Und ganz wichtig eigentlich, er kriegt nie das Passwort von dem Benutzer zu sehen. Das heißt, das bleibt komplett außen vor.

So, jetzt ist ganz schematisch nochmal dargestellt, die Komponenten, die da beteiligt sind.

Kaffee. Früher Nachmittag, ne? Genau, auf der einen Seite haben wir den Benutzer, vertreten eigentlich durch seinen Browser.

Auf der anderen Seite haben wir dann die zwei Komponenten, einmal den Identity Provider, das wäre in dem Fall mir.

Das heißt, das ist der Part, der die Benutzer kennt und unten dann den Service Provider, das heißt, den eigentlichen Diensteanbieter,

zum Beispiel bei uns jetzt hier irgendein externer Verlag. Zum Identity Provider, der macht die eigentliche Abmeldifizierung des Benutzers.

Normalerweise, wie auch in unserem Fall hier, mittels Benutzernahma in Passwort. Und er sichert quasi dem Service Provider,

übergibt er irgendwelche Attribute und sichert ihm zu, dass die korrekt sind.

Das kann man dann quasi pro Service Provider entscheiden, das heißt, ein Dienst braucht eventuell mehr Attribute,

zum Beispiel eine Mailadresse, während ein anderer gar nichts von dem User braucht. Der will nur wissen, das ist ein Benutzer von der FAU.

Der Service Provider auf der anderen Seite natürlich bietet dem Benutzer seinen Dienst an. Die Authentifizierung lagert er aus,

das heißt, die macht er gar nicht, wenn man so will. Was er natürlich machen muss, er muss das, was er vom Identity Provider übergeben bekommt, trauen,

das heißt, er muss uns glauben. Und ganz entscheidend er hält eigentlich nie das Passwort vom Benutzer, das heißt, die Eingabe, die Log-in läuft nicht bei ihm.

Ich habe jetzt hier die ganze Zeit Attribute in Anführungszeichen gesetzt, was ist das überhaupt?

Attribute, ja, das können beliebige Natur sein. Es gibt auch gerade im Hochschulumfeld schon vordefinierte Schemata,

die die Kooperation und die Kommunikation erleichtern, das heißt, ich muss nicht jedes Mal neu erklären,

ich übergebe dir die E-Mail-Adresse, was ist das? Also bei E-Mail-Adresse ist das noch eindeutig, aber wenn wir jetzt zu so einem Attribut,

wie dieses Edu-Person-Scope-Affiliation kommen, wird es schon schwieriger, was ist das? Das ist so in diesen Schemata beschrieben,

dass es eben feste Werte enthält, wie Employee, Student, Member und auch erklärt wird, was das bedeutet.

Das heißt, man einigt sich auf was und dadurch wird die Kooperation vor allem mit sehr vielen Service Providern vereinfacht.

Andere Attribute, ganz normal jetzt wie hier meine Nachname, kann man sich beliebig auch vorstellen,

also das geht hin bis zu Geburtsdatum, Matrikelnummer, Fächerrichtung, komplexere Attribute, also da ist eigentlich alles möglich.